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REMARKS/ARGUMENTS 

Reconsideration and allowance in view of the above amendments and the 
following comments are respectfully requested. Upon entry of this amendment, claims 1-17 
will remain in the application. 

In the Official Action, the Examiner requested that Applicant amend the 
specification at pages 7, 10, 19 and 25 to update the status of the referenced patent 
applications. Applicant has accordingly amended the specification. 

Applicant has amended the application to provide a reference to U.S. Patent 
Application Serial No. 09/310,543, from which Applicant claims priority under 35 USC 120. 
Acceptance of this claim for priority is requested. 

Applicant has submitted herewith formal drawings for overcoming the 
draftsperson's objections. Entry of the formal drawings is requested. 

Objections to the Drawings 

The drawings have been objected to under 37 CFR 1.83(a) as allegedly not 
showing a plurality of closely coupled networked computer systems as recited in claims 1 
and 15 or the filtering device of claims 13 and 16. This objection is respectfully traversed. 

The drawings do not illustrate a plurality of closely coupled networked 
computer systems as such a drawing would be quite cluttered and difficult to understand. 
Applicant does not believe that such a figure is necessary to understand the claimed subject 
matter. If the Examiner maintains this objection, the Examiner is asked to provide guidance 
on what type of drawing would be desirable and acceptable. 

The "filtering device" referenced in claims 13 and 16 is described with respect 
to Figures 28 and 30 as combinations of Open(Passive) requests from the DTCM client, TDI 
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Listen requests from the DTCM server, and Open Abort requests from the DTCM client that 
together function to ensure that dialog connections are made only for the proper network 
environment. This feature of the invention is also described in the specification at page 72, 
line 19, through page 74, line 24. To make this less confusing to the Examiner, Applicant has 
also deleted reference to "filtering" from claims 13 and 16, for though that function is 
described on the recited pages, different terminology is used. 

In view of the above, withdrawal of the objection to the drawings is requested. 

Objection to the Specification 

The Examiner objected to the specification under 37 CFR 1.74 as allegedly 
not containing references to Figures 21-23. Applicant notes that Figure 21 is referenced at 
page 39, line 16, through page 40, line 13, that Figure 22 is referenced at page 40, lines 16- 
31, and that Figure 23 is referenced at page 41, lines 1-9. Accordingly, Applicant 
respectfully requests that the Examiner withdraw the objection to the specification. 

Rejections of the Claims 

Claims 1-12 and 15 stand rejected under 35 U.S.C 103(a) as allegedly being 
obvious over Szwerinski et al. (USP 5,517,668). In addition, claims 1-16 stand rejected 
under 35 USC 103(a) as allegedly being obvious over Narisi et al. (USP 6,233,619). 
Although claim 17 is not mentioned in the rejection, Applicant will treat claim 17 in 
conjunction with independent claiml5 below. These rejections are respectfully traversed for 
the reasons given below. 

The Invention 

The present invention involves methods and apparatus that enable a transport 
protocol executing on a first computer system to be utilized by applications executing on a 
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second computer system that is directly interconnected and closely coupled to the first 
computer system in a manner that is transparent to the applications. The apparatus is 
characterized by an interconnection coupling an input/output (I/O) subsystem of the first 
computer system to an I/O subsystem of the second computer system without the use of a 
network interface card as in conventional network configurations and an interconnection 
messaging system executing on the first and second computer systems that provides general 
purpose transport interfaces between the computer systems via the interconnection. The 
invention is particularly characterized by a distributed transport communications manager 
executing on the first and second computer systems so as to control the use of the 
interconnection messaging system to establish a dialog through which the transport protocol 
of the first computer system may be used by an application executing on the second computer 
system in a manner which is transparent to the application. The invention is further 
characterized in that the application executing on the second computer system may utilize the 
transport protocols executing on a plurality of networked computer systems including the first 
computer system that are directly interconnected and closely coupled to the second computer 
system. A plurality of dialogs are established to permit the application to utilize designated 
protocols of any of the networked computer systems. As with the parent application (U.S. 
Application Serial No. 09/310,543). the respective computers are directly at the transport 
level as opposed to the physical level (as in Ethernet applications) or the data link level (as 
with the virtual LAN application in USP 6,473,803), or through a simulated TCP transport 
protocol and IP networking protocol as described in USP 6,233,619. 

As described in the specification, the DTCM-Client 90 of the invention may 
utilize more than one DTCM-Server 94 so it creates a new MSS Endpoint-Dialog and issues 
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an Open (Passive) request for each DTCM-Server 94. This allows the original application 
passive open to be satisfied by an incoming connect request directed at any DTCM-Server 94 
environment. When the first corresponding Query-Accept request is received, DTCM-Client 
90, in addition to issuing a Query- Accept response, also issues an Open- Abort request to each 
of the other DTCM-Servers. On processing an Open- Abort request, DTCM-Server 94 
rescinds the corresponding TDI-Listen requests, thus limiting the dialog to a particular 
DTCM server 94. 

As also described in the specification, handling configurations in which a 
DTCM-Client 90 utilizes more than one network address in a particular Protocol 
Environment is under the control of DTCM-Server 94. On receipt of an Open (Passive) 
request, if the request indicates that it may be satisfied by an incoming request for any of the 
MCP environment network addresses resident in the DTCM-Server 94 Protocol 
Environment, a set of TDI-Listen requests is generated- Each of these TDI-Listens indicates 
that it may be satisfied only by an incoming connect request to a specific MCP environment 
network address, and one TDI-Listen is generated for each such MCP environment network 
address. When any one of these TDI-Listen requests is completed, all the other requests 
issued for the corresponding Open (Passive) request are rescinded. This mechanism ensures 
that Open (Passive) requests are satisfied only by incoming connect requests for one of the 
MCP environment network addresses, thereby limiting the dialog to a particular DTCM client 
90. 

This dialog mechanism effectively "filters" between the TCP/IP stack of the 
first computer system and the application programs to establish a connection using 
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independent IP addresses for each environment so that multiple applications may be used 

simultaneously in multiple environments. 

These characteristic features of the invention are clearly set forth in independent 

claim 1 5 which recites an apparatus including the above-mentioned interconnection and 

interconnection messaging system as well as a "distributed transport communications 

manager executing on the first and second computer systems" so as to control use of the 

interconnection messaging system 

to establish a dialog through which the transport protocol 
of the first computer system may be used by an application executing 
on the second computer system in a manner which is transparent to 
said application, wherein said application utilizes transport protocols 
executing on a plurality of networked computer systems including said 
first computer system, each of said plurality of networked computer 
systems being directly interconnected and closely coupled to said 
second computer system and using said interconnection messaging 
system to establish dialogs through which the transport protocols of the 
networked computer systems may be used by said application in a 
manner which is transparent to said application. 

Such characteristic features are not believed to be shown or suggested by the 

cited prior art. 

Patentability over Szwerinski et al 

Szwerinski et al. disclose a distributed computing system that implements a 
distributed protocol stack to off-load communication or other I/O processing from the 
application processor to dedicated I/O processors using the well-known UNIX STREAMS 
framework. The distributed protocol stack is formed of a stack top used by the application 
processor and a stack bottom used by the I/O processor (Figure 2) that together constitute a 
full stack functionally equivalent to a non-distributed stack running on the application 
processor. Two STREAMS media drivers 57 and 58 (Figure 3) communicate over a physical 
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channel 60 between the distributed streams facility (DSF) environments of the application 
processor and I/O processor. DSF upper driver 55 links the media driver 57 and the media 
driver 61 to allow the exchange of DSF related protocol information with the remote (I/O) 
environment 62. DSF upper driver 55 further establishes a bridge between the local UNIX 
STREAMS environment 54 and the remote STREAMS environment 62 and coordinates the 
actions of the two streams environments (column 12, lines 4-28). 

Applicant submits that even if the STREAMS environment of Szwerinski et al. 
may be analogized to the claimed interconnection messaging system as the Examiner 
proposes in the rejection, Szwerinski et al. fail to disclose the claimed interconnection 
coupling the I/O subsystems of first and second computer systems. On the contrary, 
Szwerinski et al. teach that the I/O processor is off-loaded from the application processor and 
does not suggest that separate I/O subsystems of separate computers communicate over the 
claimed interconnection that is independent of a network interface card. 

Moreover, Szwerinski et al. do not disclose the claimed distributed transport 
communications manager that controls the interconnection messaging system to establish a 
dialog through which the transport protocol of one computer system may be used by an 
application executing on the other computer system as claimed. On the contrary, Szwerinski 
et al. use the STREAMS facility to permit stack references made in the stack top 15 to the 
stack bottom 16 to be transferred to the stack bottom 16 so that the stack may be distributed 
between processors. The claimed invention does not distribute the stack in this manner. 
Szwerinski et al. nowhere disclose that the transport protocol (e.g., TCP) of one computer 
system may be transmitted from the application processor via a dialog over the STREAMS 
interface to the I/O processor for processing by an I/O application. The STREAMS 
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framework moves data modules from one processor to another at the data link and physical 
levels. Applicant can find no mention by Szwerinski et al. of off-loading of the transport 
protocol from the applicant processor to an application of the I/O processor or the teaching of 
off-loading the transport protocol from one computer to an application on another computer 
as claimed. 

In view of these differences, Applicant submits that there is no support for the 
Examiner's allegation that it would have been obvious to one skilled in the art to modify the 
system of Szwerinski et al. to allow the application on the second computer to access multiple 
protocol stacks operating on different I/O processors. Applicant finds no such suggestion and 
does not appreciate how the STREAMS framework would the use of network protocol stacks 
by an application program on a closely coupled computer as claimed. 

Accordingly, Applicant submits that Szwerinski et al. fall far short of 
suggesting the claimed invention to one skilled in the art. Withdrawal of the rejection of 
claims 1-12 and 15 over Szwerinski et al. is thus solicited. 

Patentability over Narisi et al 

Applicant acknowledges the Examiner's indication that the cited Narisi et al. 
patent (USP 6,233,619) is available as prior art only under 35 U.S.C. 102(e). While 
Applicant will provide comments below in an effort to distinguish the claimed invention from 
the teachings of Narisi et al., Applicant reserves the right to establish that the Narisi et al. 
patent is not available as prior art under 35 USC 102(e). 

Prior to discussing the Narisi et al. patent, Applicant notes that the rejection 
over Narisi et al. is unclear. In particular, the Examiner alleges that it would have been 
obvious to combine Narisi' s teaching regarding shared network interface cards with the 
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system of Narisi by having the A series system establish a dialog with the transport stack of 
the NT server using the MSS. How can the Narisi et al. patent be combined with itself? 
What specific teachings of the Narisi et al. patent are being relied upon by the Examiner? 
Also, it is unclear to Applicant how method claim 15 corresponds to apparatus claim 3 as the 
Examiner suggests. If the Examiner maintains the rejection over the Narisi et al. patent, the 
Examiner is asked to clarify these points in the next Official Action. 


of the present application at the paragraph bridging pages 1 0 and 1 1 . As noted therein, Narisi 
et al. simulate the TCP transport protocol and the IP networking protocol between the A 
series enterprise server 100 and the NT server 102 via the interconnect so that data may be 
transferred point to point between systems at the transport level rather than the data link level. 
By simulating the transport and network layer protocols over the interconnect, the patented 
Narisi et al. system provides for communication over a more reliable network connection 
through which larger blocks of data may be transmitted without being broken up into smaller 
data chunks with prepended network protocol information as would be the case over a 
conventional network interface. However, the Narisi et al. patent does not teach that a 
known transport protocol executing on one computer system may be utilized by applications 
on another, tightly coupled computer system in a way that is transparent to the application, 
i.e., no application programming changes are needed. On the contrary, Narisi et al. use a 
virtual transport protocol between two processing environments rather than providing a 
mechanism for the use of a network protocol (e.g. TCP) of one computer by applications of 
the other computer. As a result, Narisi et al. do not permit (without further system 


The commonly owned Narisi et al. patent is noted in the background portion 
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modification) communications amongst multiple processing environments that share a 
network protocol. 

Accordingly, Narisi et al. also fail to teach or suggest the claimed "distributed 
transport communications manager" that establishes a dialog "through which the transport 
protocol of the first computer system may be used by an application executing on the second 
computer system in a manner which is transparent to said application" as claimed. Narisi et 
al. also fail to teach the use of multiple dialogs to permit the utilization of transport protocols 
executing on a plurality of closely coupled networked computer systems as claimed. As 
similar features may be found in independent method claim 15 and are incorporated by 
reference into dependent claims 2-14, 16 and 17, respectively, claims 2-17 are allowable for 
the same reasons as set forth above with respect to claim 1. Allowance of claims 1-17 over 
the teachings of Narisi et al. is thus respectfully solicited. 

Obviousness-type Double Patenting Rejection 

Claims 1-17 stand provisionally rejected under the doctrine of obviousness- 
type double patenting as allegedly being obvious over claim 11 of copending U.S. Patent 
Application Serial No. 09/310,543 in view of Narisi et al. 6,233,619. This rejection is 
respectfully traversed in that Narisi et al. do not teach utilizing transport protocols executing 
on a plurality of directly interconnected networked computer systems. Therefore, it cannot 
do so by establishing dialogs through which the transport protocols may be used. Absent 
such teachings, this rejection is improper and should be withdrawn. If the Examiner 
maintains this rejection, the Examiner is asked to identify specific teachings in the Narisi et 
al. patent that support the use of dialogs to permit the utilization of transport protocols 
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executing on directly interconnected networked computer systems as claimed. Withdrawal of 
the obviousness-type double patenting rejection is solicited. 


In view of the above, Applicant does not believe that a Terminal Disclaimer is 


necessary to overcome the rejection. However, Applicant reserves the right to submit a 
Terminal Disclaimer at a later date as necessary to obtain allowance. 


For all the foregoing reasons, Applicant respectfully submits that the 


Examiner's conclusion as to obviousness are incorrect as unsupported by the cited prior art. 
Withdrawal of the prior art rejections and a Notice of Allowability are respectfully requested. 


Unisys Corporation 
Unisys Way 
MS/E8-114 

Blue Bell, PA 19424-0001 
Telephone: (215) 986-3128 
Facsimile: (215)986-3090 


CONCLUSION 


Date: December 23, 2003 



Respectfully submitted; 
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